1. Technical Field
This invention relates generally to public key cryptography, public key management infrastructure, and digital certificates issued by a certification authority (CA) to a subscriber, which together form part of a public key infrastructure (PKI). More specifically, the invention relates to computer-implemented techniques for permitting a certificate services provider (CSP) to generate a digital signature using a private key of a CA while simultaneously protecting the integrity of the private key.
2. Background Art
Public key cryptography is an approach to enabling secure communications using key pairs. Each key pair includes a public key and a private key. The public key and private key are related so that a message encrypted by one key may be decrypted only by the other, but it is computationally infeasible to deduce the private key given the public key. The private key is typically created and securely held by an entity; while the corresponding public key is typically made widely available. Secure communications between parties may then be enabled by using the parties"" public and private keys.
The use of public key cryptography addresses many of the inherent security problems in an open network such as the Internet. However, two significant problems remain. First, parties must be able to access the public keys of other entities in an efficient manner. Second, since in many protocols entities are associated with and in some sense identified by their public keys, there must be a trustworthy method for parties to verify that a certain public key is bound to a certain entity.
A public key management infrastructure addresses both of these problems. In one common approach, the public key management infrastructure is based on digital certificates, which are used to associate a certain public key to a certain entity with some degree of integrity. A third party, commonly known as a certification authority (CA), issues digital certificates to subscribers. Each digital certificate typically includes the subscriber""s public key along with other information about the subscriber, including information identifying the subscriber. One purpose of the digital certificate is to document with some integrity that the public key is associated with the subscriber. In other words, the digital certificate is a representation by the CA that the subscriber identified in the digital certificate holds the private key corresponding to the public key contained in the digital certificate. The integrity of the digital certificate is ensured because the CA digitally signs the digital certificate with his private key. Third parties who wish to verify that a certain public key corresponds to a certain subscriber may do so by examining the corresponding digital certificate, evaluating the CA""s digital signature on the digital certificate, and assessing the trustworthiness of the CA issuing the digital certificate.
In certain situations, however, the CA issuing digital certificates may not want to actually generate the digital signatures for these digital certificates. Rather, the CA may have a certificate services provider (CSP) generate the digital signatures. In order to do this, the CSP must have access to the CA""s private key but, for security purposes, the CA typically would prefer not to reveal its private key to the CSP.
Cryptographic signing units (CSUs) are often used to meet these two apparently conflicting requirements. A CSU is a container for securely storing keys and/or key pairs and typically also includes certain functionalities required to use the key pairs, for example the ability to generate digital signatures and/or decrypt messages using the private and public keys stored within the CSU. Hence, by using a CSU which contains the CA""s private key, a CSP can generate the digital signatures required on digital certificates issued by the CA but without requiring the CA to reveal the private key.
The CSP typically operates a computer system for providing certificate services and would install a CSU with the CA""s key pair on the system in order to provide the digital signing service described above. The CSP often must manage a large quantity of key pairs and the corresponding CSUs for its customers and also must be able to provide continuous uninterrupted service. On the other hand, the CSP must also be able to make changes to the key pairs which are currently activated on its system. For example, an activated key pair may be deactivated if compromised, a new key pair and new CSU may be installed and activated for a new customer, or a new key pair may be added to an existing CSU for an existing customer.
However, new key pairs are typically generated and stored in CSUs in a highly secure key generation procedure at a location separate from the CSP""s system. The CSU is then physically transported to the CSP""s system and installed. This is operationally disruptive because a new CSU must be individually installed for each new CA. Furthermore, for a CSU to which a new key pair is to be added, the CSU must first be de-installed from the system, the new key pair generated and stored to the CSU, and then the CSU is re-installed. For the duration of the key generation procedure, the CSU and all of the key pairs previously stored within it will not be available to the CSP""s system. In addition, since a CSP may make a fair number of changes to the key pairs on its system, the amount of physical activity required to execute the key generation procedure and install the resulting CSU for each individual key pair is significant.
As an additional drawback, key pairs stored in a CSU are typically identified by the distinguished name of the CA to which the key pairs are assigned. However, a single CA may use multiple key pairs, for example for different digital certificates or for different purposes. These key pairs will all be identified by the same name (i.e., the CA""s distinguished name) and, therefore, must be stored in different CSUs since most CSUs do not allow the storage of key pairs with the same name. This leads to the proliferation of CSUs and more physical activity to maintain the increased number of CSUs.
Thus, there is a need for approaches which allow a CSP to use CSUs but which reduces the operational disruption of continuously de-installing and installing CSUs and which also reduces the physical activity required to generate key pairs and install the corresponding CSUs. There is further a need for approaches which allow multiple key pairs for a single CA to be stored in a single CSU.
In accordance with the present invention, a method (200) for assigning a first key pair to an entity, such as a CA (102), includes the following steps. A first key pair is generated (210). It includes a first private key and a first public key which form a key pair for use in public-key cryptography. The first key pair is stored (220) in a CSU (140). The CSU (140) is then activated (230). A first request for a key pair is received (240) from the entity (102). Responsive to the first request, the first key pair is assigned (250) to the entity (102). In a preferred embodiment, an identifier (312) is assigned to the first key pair and preferably is different from the identifiers assigned to other key pairs stored in the CSU (140). The identifier (312) is also included in a digital certificate (300) issued to the entity (102). In another aspect of the invention, a computer readable medium stores the digital certificate (300).
In another aspect of the invention, a private key of an entity (102) and a corresponding public key form a key pair for use in public-key cryptography. The key pair is stored in a CSU (140) and is assigned an identifier (312). A method (400) for digitally signing a message with the private key includes the following steps. A request to digitally sign a message with a private key of an entity (102) is received (410). The identifier (312) for the private key is also received (410). A digital signature of the message is generated (430) using the private key identified by the identifier (312). In another aspect of the invention, a system for providing digital certificate services includes a certificate services engine (120) for executing the above steps and a CSU interface for coupling the CSU (140) with the certificate services engine (120).
The present invention has numerous advantages. For example, since key pairs are generated (210) and stored (220) on the CSU (140) independent of the CA""s (102) actual requests for key pairs, a large quantity of key pairs may be generated (210) and stored (220) on a large number of CSUs (140) at the same time. The resulting CSUs (140) may then be activated (230) on the CSP""s (104) system at the same time. In other words, the key pairs may be generated (210), stored (220), and activated (230) in batch mode rather than one at a time as CAs (102) request them. This process may be automated, reducing the amount of physical activity required. In addition, since CSUs (140) with pre-stored key pairs are already installed when a new CA (102) requests a key pair or an existing CA (102) requests an additional key pair, the CSU (140) need not be de-installed and re-installed, thus significantly reducing any operational disruption. As a final example, since different key pairs within a CSU (140) are assigned different identifiers (312), a single CSU (140) may be used to store multiple key pairs used by a CA (102), thus reducing the number of CSUs (140) required.